REMARKS 

Careful review and examination of the subject application 
are noted and appreciated. 

SUPPORT FOR THE CLAIM AMENDMENTS 

Support for the claim amendments may be found in the 
specification, for example, on page 14 line 11-page 15 line 10 and 
in FIGS. 2 and 3, as originally filed. Thus, no new matter has 
been added. Since the amendments should only require a cursory 
review, entry of the amendments is respectfully requested under 
MPEP §714.13 II. If the amendments are not entered, Applicant 
respectfully requests a concise explanation per MPEP §714.13 III 
for purposes of appeal. 

OBJECTION TO THE CLAIMS 

The objection to claim 18 for informalities has been 
obviated by appropriate amendment and should be withdrawn. 

CLAIM REJECTIONS UNDER 35 U.S.C. §102 

The rejection of claims 1-8 and 10-16 under 35 U.S.C. 
§102 (e) as being anticipated by Ogawa et al . x 966 (hereafter Ogawa) 
has been obviated in part by appropriate amendment, is respectfully 
traversed in part, and should be withdrawn. 
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Ogawa concerns a data receiving device which enables 
simultaneous execution of processes of a plurality of protocol 
hierarchies and generates header end signals (Title) . 

The Federal Circuit has stated that "[t]o anticipate, 
every element and limitation of the claimed invention must be found 
in a single prior art reference, arranged as in the claim." 1 
(Emphasis added) . The Federal circuit has added that the 
anticipation determination is viewed from one of ordinary skill in 
the art: "There must be no difference between the claimed invention 
and the reference disclosure, as viewed by a person of ordinary 
skill in the field of the invention." 2 Furthermore, "A claim is 
anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently described, in a 
single prior art reference." 

Claim 1 provides a step for reading a pointer for a first 
parameter within an incoming packet (from a first network) . The 
Office Action asserts that column 13, lines 50-55 of Ogawa disclose 
a pointer similar to the claimed pointer: 



1 Brown v. 3M, 60 USPQ2d 1375, 1376 (Fed. Cir. 2001) citing 
Karsten Mfg. Corp. v. Cleveland Golf Co., 242 F.3d 1376, 1383, 58 
USPQ2d 1286, 1291 (Fed. Cir. 2001); Scripps Clinic & Research 
Found, v. Genentech Inc., 927 F.2d 1565, 18 U.S.P.Q.2d 1001, 1010 
(Fed. Cir. 1991) (Emphasis added by Appellant) . 

2 Scripps Clinic & Research Found, v. Genentech Inc., 927 
F.2d 1565, 18 U.S.P.Q.2d 1001, 1010 (Fed. Cir. 1991). 
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Incidentally, the TCP protocol information TC4 indicates an 
acknowledge number; the TCP protocol information TC5,- an 
of f set /flag; the TCP protocol information TC6, a window; the 
TCP protocol information TC8, an object pointer; and the TCP 
protocol information TC9, an optional field. (Emphasis added) 

The TCP protocol object pointer appears to be the pointer cited in 

the Office Action. The Office Action asserts that column 13, lines 

15-21 of Ogawa discuss a parameter similar to the claimed first 

parameter within an incoming packet from a first network: 

Thereafter, the MAC header data MAH is received in accordance 
with WR1 to WR7 . The MAC header data MAH is constituted by 

MAC address data MAA and protocol type data ET. In 
particular, a type of the following IP protocol can be 
identified by the protocol type data ET. In addition, MAC 
capsule data LLl of DO is determined by the MAC address data 
MAA and the protocol type data ET. The MAC capsule data LLl 
is output in synchronism with SBl to SB4 . (Emphasis added) 

While the Office Action does not specifically identify which 

element in the above text is allegedly similar to the claimed first 

parameter, the text appears to indicate that all of the above 

elements are part of a MAC header data. Ogawa further states that 

the MAC layer is part of the second (data link) layer of the OSI 

model (see Ogawa column 2, lines 5-8). In contrast, the object 

pointer in the TCP protocol is part of the fourth (transport) layer 

of the OSI model (See Appendix A, pages A-4 and A-5) . One of 

ordinary skill in the art would not appear to understand a pointer 

in a transport layer to be for a parameter in a data link layer. 

Therefore, the TCP object pointer of Ogawa appears to have no 

connection to the MAC header data of Ogawa as asserted in the 

Office Action. Thus, Ogawa does not appear to disclose or suggest 
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a step for reading a pointer for a first parameter within an 
incoming packet as presently claimed. As such, the Examiner is 
respectfully requested to either (i) identify the element within 
the MAC header data allegedly similar to the claimed first 
parameter and provide evidence that one of ordinary skill in the 
art would understand the TCP object pointer to be for that MAC 
header data element or (ii) withdraw the rejection. 

Claim 16 provides language similar to claim 1 and adds 
the structure of a means for reading the pointer. In contrast, 
none of the above cited text of Ogawa appears to expressly or 
inherently mention a means for reading the TCP object pointer. 
Therefore, prima facie anticipation has not been established for 
lack of evidence that the reference discloses all of the claim 
elements as arranged in the claims. As such, the Examiner is 
respectfully requested again to either (i) identify the structure 
in Ogawa asserted responsible for reading the pointer or (ii) 
withdraw the rejection. 

Claim 1 further provides a step for processing the first 
parameter in accordance with the pointer to produce a second 
parameter. The Office Action asserts that Ogawa discusses 
processing the unidentified MAC header data element (asserted 
similar to the claimed first parameter) in accordance with the TCP 
object pointer (asserted similar to the claimed pointer) in column 
13, lines 15-21, reproduced above. However, nothing in Ogawa 
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column 13, lines 15-21 appears to talk about processing any of the 
elements in the MAC header data in accordance with the TCP object 
pointer. As such, the Examiner is respectfully requested to either 
(i) clearly identify the alleged processing function on the 
unidentified MAC header data in accordance with the TCP object 
pointer or (ii) withdraw the rejection. 

Claim 1 further provides that the processing of the first 
parameter in accordance with the pointer produces a second 
parameter. The Office Action asserts that Ogawa discusses a 
parameter similar to the claimed second parameter in column 9, 
lines 7-24: 

Further, by output ting the destination network address as the 
retrieval key data signal SKD2, an entry having the same 
value as the output retrieval key data signal SKD2 in the 
network address field can be found in each entry of the 
retrieval table, and it is possible to obtain a PID with 
which a host computer that is to receive the data frame and 
a MAC address of that computer by reading that entry. In 
addition, if a CAM having the retrieval table configuration 
of which is shown in FIG. 6 is used as the external circuit, 
judgment is made upon whether the data frame is to be relayed 
to enable the firewall to be constructed by outputting the 
transport layer protocol code, the transport layer port 
number, the source network address and the destination 
network address as the retrieval key data signal SKD2 and 
retrieving whether entries having the same data exist in the 
table. In this judgment, relay may be enabled if entries 
having the same data exist in the table, or it may be enabled 
if entries having the same data do not exist in the table. 

While the Office Action fails to identify which of the above 
elements is allegedly similar to the claimed second parameter, none 
of the above elements of Ogawa appear to be the product of an 
unidentified processing of an unidentified MAC header data element 
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(asserted similar to the claimed first parameter) in accordance 
with the TCP object pointer (asserted similar to the claimed 
pointer) . Therefore, Ogawa does not appear to disclose or suggest 
a step for processing a first parameter in accordance with a 
pointer to produce a second parameter as presently claimed. As 
such, the Examiner is respectfully requested to either (i) clearly 
identify the element in column 9, lines 7-24 of Ogawa allegedly 
similar to the claimed second parameter and show where Ogawa 
mentions that the unidentified element is produced from the 
unidentified MAC header data element or (ii) withdraw the 
rejection. 

Claim 16 further provides language similar to claim 1 and 
adds the structure of a means for processing the first parameter. 
In contrast, the cited text of Ogawa does not appear to mention any 
structure for processing the unidentified MAC header data (asserted 
similar to the claimed first parameter) in accordance with the TCP 
object pointer (asserted similar to the claimed pointer) . 
Therefore, prima facie anticipation has not been established for 
lack of evidence that the reference expressly or inherently 
discloses each and every element as arranged in the claims. As 
such, the Examiner is respectfully requested again to either (i) 
identify the structure of Ogawa allegedly similar to the claimed 
means for processing or (ii) withdraw the rejection. 
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Claim 1 further provides a step for presenting an 

outgoing packet containing the second parameter for a second 

network. The Office Action asserts that Ogawa column 8, lines 50- 

63 mentions presenting an outgoing packet on a second network 

containing the unidentified element (allegedly similar to the 

claimed second parameter) : 

. . .a retrieval sequencer 25B which is started up by a control 
signal SEC from the sequencer 32, executes the retrieval 
operation with respect to the external CAM circuit by 
outputting the retrieval data selection signal and the SCK2 , 
changes a sequence for retrieval using the HIT signal output 
from the CAM and directs a later-described retrieval result 
register 25C to store/hold a retrieval result reading signal 
by outputting a retrieval result holding signal; and a 
retrieval result register 25C which stores/holds the 
retrieval result reading signal in response to the direction 
from the retrieval sequencer 25B and can be read by the 
external CPU as a part of the capture register circuit 24. 

The retrieval key data signal SDK2 and the retrieval data 
synchronizing signal SCK2 are used to output a destination 
address of the received frame data to the external circuit 40 
for executing various processes outside. 

The only element" in the above text common to the text of Ogawa in 

column 9, lines 7-24 appears to be the retrieval key data signal 

SDK2 . However, noting in the above text, or in any other section 

of Ogawa appears to mention the retrieval key data signal SDK2 

being part of an outgoing packet on an unidentified second network. 

Therefore, Ogawa does not appear to disclose or suggest a step for 

presenting an outgoing packet containing a second parameter for a 

second network as presently claimed. As such, the Examiner is 

respectfully requested to either (i) clearly identify the element 

in Ogawa column 8, lines 50-63 allegedly similar to the claimed 
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second parameter, clearly identify the text of Ogawa allegedly 
showing the unidentified element (claimed second parameter) in an 
outgoing packet and clearly identify a network of Ogawa allegedly 
similar to the claimed second network on which the unidentified 
outgoing packet is presented or (ii) withdraw the rejection. 

Claim 16 further provides language similar to claim 1 and 
adds the structure of a means for presenting the outgoing packet. 
In contrast, the cited text of Ogawa does not appear to mention any 
structure for presenting an outgoing packet. Therefore, prima 
facie anticipation has not been established for lack of evidence 
that the reference expressly or inherently discloses each and every 
element as arranged in the claims. As such, the Examiner is 
respectfully requested to either (i) identify the structure of 
Ogawa allegedly similar to the claimed means for presenting or (ii) 
withdraw the rejection. 

Claim 2 provides a step for reading a length and an 

offset for the first parameter from a database storing the pointer. 

The Office Action asserts that Ogawa discusses reading a length and 

an offset for the unidentified MAC header data element (asserted 

similar to the claimed first parameter) in column 9, lines 27-65: 

FIG. 7 shows an example of a series of retrieval 
operations carried out by the second cut- through circuit 25 
in a bridge, and FIGS. 8 through 10 show the operation of 
each signal. FIGS. 8 to 10 divide the continuously- lapsed 
operation into three for the convenience's sake. 

Also, FIG. 11 shows an example of a series of retrieval 
operations executed by the second cut-through circuit 25 in 
a router. 
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The protocol recognition circuit 26 identifies a protocol 
type of each protocol hierarchy by comparing a protocol type 
represented by a protocol type signal PT input from the 
capture register circuit 24 or a protocol type indicated by 
the frame data FD2 output from the input data control circuit 
22 with a predetermined protocol code for checking 
coincidence. 

Here, the frame data FD2 directly input from the input 
data control circuit 22 to the protocol recognition circuit 
2 6 is only of a network layer protocol type included in the 
MAC layer header. A code signal indicating a type of any 
higher protocol hierarchy, which was temporarily stored in 
the capture register 24A, is input to the protocol 
recognition circuit 26. That is because the code representing 
the network layer protocol corresponds to the end of the MAC 
header and, if it is stored in the capture register 24A, it 
will not be ready for the network layer header processing. 

Note that a result of recognition of a protocol type by 
the protocol recognition circuit 26 is output to the sequence 
selection circuit 28 or the header end timing detection 
circuit 36 as a protocol identification code signal PTN and 
also output to the external circuit such as a computer 
through the CPU bus as a protocol identification code signal 
PTN2. 

The sequence selection circuit 28 generates a sequence 
selection signal SES for selecting a process for each 
protocol hierarchy of the received frame data based on a 
result of recognition of a protocol type output from the 
protocol recognition circuit 26 and changes the sequence 
selection signal SES corresponding with each protocol 
hierarchy in accordance with a header end signal PHE output 
from the header end timing detection circuit 36. 

Nowhere in the above text, or in any other section does Ogawa 

appear to discuss a length and an offset for a MAC header data 

element. Therefore, Ogawa does not appear to disclose or suggest 

a step for reading a length and an offset for the first parameter 

from a database storing the pointer as presently claimed. 

Claim 2 further provides a step for partitioning the 

incoming packet in accordance with the offset and the length to 

extract the first parameter. The Office Action again asserts that 
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the claimed partitioning step is discussed in the above reproduced 
text. However, nowhere in the above text, or in any other section 
does Ogawa appear to discuss partitioning an incoming packet in 
accordance with an unidentified offset and an unidentified length 
to extract an unidentified MAC header data element (asserted 
similar to the claimed first parameter) . Therefore, Ogawa does not 
appear to disclose or suggest a step for partitioning an incoming 
packet in accordance with an offset and a length to extract a first 
parameter as presently claimed. As such, claim 2 is fully 
patentable over the cited reference and the rejection should be 
withdrawn. 

Claim 17 provides that a structure for partitioning the 
incoming packet is part of the means for processing (the first 
parameter) . In contrast, none of the text of Ogawa cited in the 
Office Action appears to mention a structure for partitioning as 
part of a structure for processing. Therefore, prima facie 
anticipation has not been established for lack of evidence that the 
reference expressly or inherently discloses or suggests each and 
every element as arranged in the claims. As such, the Examiner is 
respectfully requested to either (i) identify the structure of 
Ogawa that allegedly performs the processing and the structure that 
allegedly performs the partitioning or (ii) withdraw the rejection. 

Claim 3 provides a step for downloading all of the 
offset, the length, and the pointer into the database prior to 
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reading. The Office Action asserts that a step similar to the 
claimed downloading is discussed by Ogawa in column 9, lines 27-65, 
as reproduced above. In contrast, none of the above text, or any 
other section of Ogawa appears to discuss a step for downloading an 
offset, a length and a pointer. In particular, Ogawa does not even 
appear to use the word "download" . 

Assuming, arguendo, that Ogawa does somehow discuss 
downloading (for which Applicant's representative does not 
necessarily agree) , Ogawa still appears to be silent that the 
downloading takes place before the alleged reading of the of the 
TCP object pointer (asserted similar to the claimed pointer) . 
Therefore, Ogawa does not appear to disclose or suggest a step for 
downloading all of the offset, the length, and the pointer into the 
database prior to reading as presently claimed. As such, claim 3 
is fully patentable over the cited reference and the rejection 
should be withdrawn. 

Claim 4 provides a step for routing the first parameter 

to at least one of a plurality of peripheral blocks identified by 

the pointer prior to processing, wherein the peripheral blocks 

perform the processing. The Office Action asserts that the claimed 

routing to a peripheral block identified by the pointer is 

discussed by Ogawa in column 3, lines 44-65: 

In a data receiving device for receiving from a network frame 
data based on any arbitrary protocol of a plurality of 
protocol hierarchies defined from a physical layer to upper 
layers, the present invention solves the above-described 
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drawbacks by comprising: an input data control circuit for 
receiving the frame data together wi th\ its synchronizing 
signals from the network and holding them in a register; a 
capture register circuit for storing/holding in accordance 
with information such as a protocol type code, a header 
length, a frame length (network layer only) , 
source/destination addresses or source/destination port or 
socket numbers included in a header for each protocol 
hierarchy constituting the frame data; a protocol recognition 
circuit for identifying a protocol type of each protocol 
hierarchy from the protocol type code stored in the capture 
register circuit; a sequence selection circuit which 
generates a sequence selection signal for selecting a 
processing for each protocol hierarchy of the recessed frame 
data in accordance with a result of identification by the 
protocol recognition circuit and changing the sequence 
selection signal in accordance with a header end signal; a 
sequence counter for counting a pulse signal in the frame 
data synchronizing signal; 

Nowhere in the above text, or in any other section does Ogawa 

appear to discuss routing an unidentified MAC header data element 

(asserted similar to the claimed first parameter) to an 

unidentified peripheral block identified by the TCP object pointer 

(asserted similar to the claimed pointer) . 

Furthermore, the Office Action asserts that the 



processing of the first parameter in the peripheral block is 

discussed in Ogawa in column 4, lines 44-60: 

In addition, if the input data control circuit includes a 
first cut-through circuit for outputting the frame data 
synchronizing signal outside according a direction of a first 
cut- through signal output from the sequencer and for 
outputting outside a content of a specific register in the 
input data control circuit according to the first cut-through 
signal in synchronism with the frame data synchronizing 
signal, source/destination addresses and others included in 
the header of each protocol hierarchy of the received data 
frame can be selectively fetched and output to external 
circuits. Therefore, information required in a destination of 
linking to which the received data frame is transmitted or 
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for the repeating process can be fetched at high speed by 
using a retrieval table formed by a CAM (Contents Addressable 
Memory) , a RAM (Random Access Memory) and others in an 
external circuit and executing table retrieval using the 
output as key data for retrieval. 

Nowhere in the above text, or in any other section does Ogawa 

appear to discuss a peripheral block processing an unidentified MAC 

header data element (asserted similar to the claimed first 

parameter) . Therefore, Ogawa does not appear to disclose or 

suggest a step for routing the first parameter to at least one of 

a plurality of peripheral blocks identified by the pointer, wherein 

the peripheral blocks perform the processing as presently claimed. 

Claim 6 provides language similar to claim 4. As such, claims 4 

and 6 are fully patentable over the cited reference and the 

rejection should be withdrawn. 

Claim 5 provides a step for reading a second offset and 
a second length for a second network protocol from a database prior 
to assembling an outgoing packet. In contrast, Ogawa appears to be 
silent regarding reading offsets and lengths from a database. 
Therefore, Ogawa does not appear to disclose or suggest a step for 
reading a second offset and a second length for a second network 
protocol from a database prior to assembling an outgoing packet as 
presently claimed. As such, claim 5 is fully patentable over the 
cited reference and the rejection should be withdrawn. 

Claim 7 provides that the step for processing the first 
parameter (step B) is at least two processes of a content 
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addressable memory process, a time to live process, a comparison 

process, a counter process, a value swapping process, a stuffing 

process, a de-stuffing process, a cyclic redundancy checksum 

process, a parity process, a f irst-in-f irst-out process, a length 

construction generator process, a header error control 

synchronization process, a frame relay lookup process, a data link 

connection identifier process, a protocol identification analysis 

process, a point-to-point protocol verification process, a 

parameter discard process, and a buffer process. The Office Action 

asserts that at least two of the claimed processes are discussed by 

Ogawa in column 3, line 60 thru column 4, line 11: 

. . .a sequence selection signal for selecting a processing for 
each protocol hierarchy of the recessed frame data in 
accordance with a result of identification by the protocol 
recognition circuit and changing the sequence selection 
signal in accordance with a header end signal; a sequence 
counter for counting a pulse signal in the frame data 
synchronizing signal; a sequencer which operates in response 
to a value of the sequence counter and the sequence selection 
signal and has a function for directing the capture register 
circuit a timing for storing/holding information included in 
the header for each protocol hierarchy and for outputting a 
second header end timing used to direct an end timing for the ' 
header when a protocol that is specified by the sequence 
selection signal and being processed has a header with a 
fixed length; and a header end timing detection circuit for 
selecting either a first header end timing obtained by 
comparing a value of the sequence counter with the header 
length of the protocol hierarchy which is being received and 
[or] the second header end timing output by the sequencer to 
generate the header end signal. (Emphasis added) 

However, none of the processes in the above text appear to operate 

on an unidentified MAC header data element (asserted similar to the 
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claimed first parameter) . Therefore, Ogawa does not appear to 
disclose or suggest that a step for processing a first parameter is 
at least two processes of a content addressable memory process, a 
time to live process, a comparison process, a counter process, a 
value swapping process, a stuffing process, a de-stuffing process, 
a cyclic redundancy checksum process, a parity process, a first-in- 
first-out process, a length construction generator process, a 
header error control synchronization process, a frame relay lookup 
process, a data link connection identifier process, a protocol 
identification analysis process, a point-to-point protocol 
verification process, a parameter discard process, and a buffer 
process as presently claimed. As such, claim 7 is fully patentable 
over the cited reference and the rejection should be withdrawn. 

Claim 11 provides a step for selecting among a plurality 
of frame delineation methods for a plurality of network protocols. 
The Office Action asserts that the claimed selecting step is 
discussed in Ogawa in column 7, line 54-column 8, line 12: 

As shown in FIG. 3, the capture register circuit 24 is 
constituted by a plurality of capture registers 24A for a 
source MAC address, a destination MAC address, a network 
layer protocol, a source IP address, a destination IP 
address, a transport layer protocol, a source port number, a 
destination port number, receive port number (PID) and 
others. Although the present invention is not restricted to 
this structure in application, this embodiment has a source 
MAC register for storing/holding a source MAC address, a 
destination MAC register for storing/holding a destination 
MAC address and a network layer protocol register for 
storing/holding a network layer protocol as registers for 
storing/holding information included in the MAC layer header; 
a frame length register (network layer only) for 



storing/holding a frame length, a transport layer protocol 
register for storing/holding a protocol code of a transport 
layer, a source network address register for storing/holding 
a source network address, a destination network address 
register for storing/holding a destination network address, 
and a header length register for storing/holding a length of 
the network layer header as registers for storing/holding 
information included in the network layer header; and a 
source port register for storing/holding a source port number 
and a destination port register for storing/holding a 
destination port number as registers for storing/holding 
information included in the transport layer header. (Emphasis 
added) 

The above text appears to be no more than a list of registers. 
Nothing in the above text discusses a step of selecting among a 
plurality of frame delineation methods for a plurality of network 
protocols. Therefore, prima facie anticipation has not been 
established for lack of evidence that Ogawa expressly or inherently 
discloses each and every element as arranged in the claims. As 
such, the Examiner is respectfully requested to either (i) clearly 
identify where Ogawa allegedly mentions a step of selecting among 
multiple frame delineation methods or (ii) withdraw the rejection. 

Claim 13 provides a step for framing the outgoing packet 
to produce a transmit frame for the second network. The Office 
Action asserts that the claimed framing step is discussed by Ogawa 
in column 3, lines 44-65, as reproduced above in the arguments for 
claim 4. In contrast, nowhere in the cited text of Ogawa does 
Ogawa appear to expressly or inherently mention framing an outgoing 
packet. In particular, the cited text of Ogawa only appears to 
discuss how to receive an incoming packet. Therefore, Ogawa does 
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not appear to disclose or suggest a step for framing the outgoing 

packet to produce a transmit frame for the second network as 

presently claimed. As such, claim 13 is fully patentable over the 

cited reference and the rejection should be withdrawn. 

Claim 14 provides a step for selecting among a plurality 

of framing methods for a plurality of network protocols prior to 

framing. The Office Action asserts that the claimed selecting step 

is disclosed by Ogawa in column 10, lines 21-36: 

The sequencer 32 is provided with a plurality of processing 
sequences corresponding with various types of protocols of a 
plurality of protocol hierarchies, and selects one from a 
plurality of the processing sequences in accordance with a 
sequence selection signal SES output from the sequence 
selection circuit 28 and executes the selected sequence 
according to a sequence counter signal CT output from the 
sequence counter 30. The sequencer 32 directs a timing at 
which information of a protocol type code, a header length, 
source/destination addresses, source/destination port numbers 
and others included in the header of each protocol hierarchy 
is stored/held to the capture register circuit 24 by 
executing the selected sequence to output a sequence control 
signal SEC, and outputs a second header end timing indicating 
the end timing for the header if the currently-executed 
protocol possesses the header having a fixed length. Further, 
the sequencer 32 directs the input data control circuit 22 to 
output a value stored in a predetermined register within the 
circuit 22 as a retrieval key data signal SKD to the external 
circuit 40 together with the synchronizing signal SCK 
relative to the retrieval key data signal SKD by outputting 
the sequence control signal SEC. (Emphasis added) 

The Office Action appears to be arguing that the sequencer 32 of 

Ogawa performs a step similar to the claimed selection 'step for a 

framing method. However, Ogawa states in column 6, lines 55-59 

that the sequencer 32 is part of a first embodiment shown in FIG. 

1. Ogawa further states that FIG. 1 "is a block diagram showing 
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the structure of a first embodiment of a data receiving device" . 

(Emphasis added) . One of ordinary skill in the art would appear to 
understand that receiving devices deframe incoming information, not 
select among multiple framing methods for transmitted information. 
Therefore, Ogawa does not appear to disclose or suggest a step for 
selecting among a plurality of framing methods for a plurality of 
network protocols prior to framing as presently claimed. As such, 
claim 14 is fully patentable over the cited reference and the 
rejection should be withdrawn. 

Claims 8, 10, 12 and 15 depended either directly or 
indirectly from independent claim 1, which is now believed to be 
allowable. As such, the presently pending invention is fully 
patentable over the cited reference and the rejection should be 
wi thdrawn . 

CLAIM REJECTIONS UNDER 35 U.S.C. S103 

The rejection of claim 9 under 35 U.S.C. §103 (a) as being 
unpatentable over Ogawa in view of "Official Notice" is 
respectfully traversed and should be withdrawn. 

The rejection of claims 18-20 under 35 U.S.C. §103 (a) as 
being unpatentable over Ogawa in view of Wilford et al . '247 
(hereafter Wilford) have been obviated in part, is respectfully 
traversed in part, and should be withdrawn. 
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Ogawa concerns a data receiving device which enables 
simultaneous execution of processes of a plurality of protocol 
hierarchies and generates header end signals (Title) . Wilford 
concerns an architecture for high speed class of service enabled 
linecard (Title) . ' 

"[T]o establish obviousness based on a combination of the 
elements disclosed in the prior art, there must be some motivation, 
suggestion or teaching of the desirability of making the specific 
combination that was made by the applicants." 3 "[T]he factual 
inquiry whether to combine references must be thorough and 
searching." 4 "This factual question ... [cannot] be resolved on 
subjective belief and unknown authority." 5 "It must be based on 
objective evidence of record." 6 The Examiner must show that (a) 
there is some suggestion or motivation, either in the references or 
in the knowledge generally available to one of ordinary skill in 
the art, to modify or combine the references, (b) there is a 
reasonable expectation of success, and (c) the prior art reference 

3 In re Kotzab, 217 F.3d 1365, 1370, 55 USPQ2d 1313, 1316 
(Fed. Cir. 2000) (citing In re Dance, 160 F.3d 1339, 1343, 48 
USPQ2d 1635, 1637 (Fed. Cir. 1998); In re Gordon, 733 F.2d 900, 
902, 221 USPQ 1125, 1127 (Fed. Cir. 1984)). 

4 McGinley v. Franklin Sports, Inc., 262 F.3d 1339, 1351-52, 
60 USPQ2d 1001, 1008 (Fed. Cir. 2001). 

5 In re Lee, 277 F.3d 1338, 1343-44, 61 USPQ2d 1430, 1434 
(Fed. Cir. 2002) . 

6 Id. at 1343, 61 USPQ2d at 1434. 
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(or combination of references) teaches or suggests all of the claim 
limitations. 7 "The motivation, suggestion or teaching may come 
explicitly from statement in the prior art, the knowledge of one of 
ordinary skill in the art, or, in some cases the nature of the 
problem to be solved." 8 Furthermore, The Court of Appeals for the 
Federal Circuit has indicated that the requirement for showing the 
teaching of motivation to combine references is "rigorous" and must 
be "clear and particular". 9 (Emphasis added) 

Regarding claim 9, the Office Action has failed to 
establish clear and particular evidence of motivation to modify 
Ogawa to make processing of a first parameter non-programmable. 
The asserted motivations (i) "to facilitate non-programmable 
processing", (ii) "enhance processing the steps taught by the 
Ogawa" and (iii) "help increase the degree of freedom of circuit 
design" provided in the Office Action are not credited to any 
reference or knowledge generally available to one of ordinary skill 
as required by MPEP §2142. Furthermore, the asserted motivations 
do not appear to arise from the nature of some problem to be solved 
per In re Huston. Instead, the Office Action appears to be 

7 Manual of Patent Examining Procedure (M.P.E.P.), Eighth 
Edition, Revised May 2004, §2142. 

8 In re Huston 308, F.3d 1267, 1278, 64 USPQ2d 1810, 1810 
(Fed. Cir. 2002), citing In re Katzab 217 F.3d 1365, 1370, 55 
USPQ2d 1313, 1317 (Fed. Cir. 2000) 

9 In re Anita Dembiczak and Benson Zinbarg, 50 U.S.P.Q.2d 
1614 (Fed. Cir. 1999) 
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improperly combining the references simply to meet the limitations 
of the claim. Still furthermore, the fact that Yusa (U.S. Patent 
No. 5,633,806) teaches a concept does not explain why one of 
ordinary skill in the art would be motivated to modify Ogawa with 
that concept. The fact that references can be combined or modified 
is not sufficient to establish prima facie obviousness per MPEP 
§2143.01. As such, prima facie obviousness has not been 
established for lack of clear and particular evidence of motivation 
to combine the references. Therefore, the Examiner is respectfully 
requested to either (i) identify the source of the asserted 
motivations and provide evidence if from knowledge generally 
available to one of ordinary skill or (ii) withdraw the rejection. 

Regarding claims 18-20, the Office Action has failed to 
provide clear and particular evidence of motivation to combine the 
references. In particular, the asserted motivations provided in 
the Office Action to (i) "enhance the handling of information 
associated with the pointer", (ii) "help the software to process 
information for the circuit", (iii) enhance supporting information 
that is within the processing means", (iv) "enhance supporting 
information that is outside the processing means" and (v) "enhance 
handling of the information over the network according to the 
network protocol used" are not credited to any reference or 
knowledge generally available to one of ordinary skill as required 
by MPEP §2142. Furthermore, the asserted motivations do not appear 
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to arise from the nature of some problem to be solved per In re 
Huston. Therefore, prima facie obviousness has not been 
established for lack of clear and particular evidence of motivation 
to combine the references. As such, the Examiner is respectfully 
requested to either (i) identify the source of the alleged 
motivations and provide evidence if from knowledge generally 
available to one of ordinary skill or (ii) withdraw the rejection. 

Claim 18 provides that the means for processing (from 
claim 16) comprises a plurality of peripheral means, at least one 
of the peripheral means (i) linked to the pointer and (ii) 
configured to perform a process involving the first parameter. The 
Office Action asserts that modules of memory in figures 9, 10, 15 
and 26 of Wilford are similar to the claimed peripheral means. The 
Office Action further asserts that "information including header" 
of Wilford is similar to the claimed first parameter. The Office 
Action also asserts that the modules of memory from Wilford can 
perform a process involving a first parameter in column 6, lines 2- 
23: 

The packet is then enqueued normally in an output queue in 
the second linecard 110. Packets from the CPU that are to be 
sent via the same linecard are written back to the outbound 
queue manager 280 from CPU 440. 

Regular packets (i.e., those other than the one sent to 
the CPU) are sent to (inbound) fabric interface 170. Once the 
packets have been sent over switch fabric 12 0 and (outbound) 
fabric interface 17 0, they arrive at outbound receiver 260 in 
the outbound linecard. The outbound linecard may be in the 
same or a different linecard 110 than that discussed above. 
The conventional MAC rewrite is done by outbound receiver 
260. Output rate pacing is performed in rate limiter 270 
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using, in one embodiment, algorithms similar to that used in 
the inbound path discussed above; in some embodiments, rate 
limiter 270 is omitted and no rate pacing is performed. 
Outbound packets are then buffered and enqueued by outbound 
queue manager 280 using outbound packet buffer 285. Outbound 
queue manager 280 and outbound packet buffer 285 are 
configured and operate similarly to inbound queue manager 240 
and its associated inbound packet buffer 245. 

Nowhere in the above text, or in any other section does Wilford 

appear to discuss modules of memory processing "information 

including header" as alleged in the Office Action. Nowhere in the 

above text does Wilford even appear to mention processing header 

information. Therefore, Ogawa and Wilford, alone or in 

combination, do not appear to teach or suggest that a means for 

processing comprises a plurality of peripheral means, at least one 

of the peripheral means (i) linked to the pointer and (ii) 

configured to perform a process involving the first parameter as 

presently claimed. As such, the Examiner is respectfully requested 

to either (i) clearly show where Wilford allegedly teaches modules 

of memory performing processing and provide evidence why one of 

ordinary skill in the art would be motivated to specifically 

combine the modules of memory from Wilford with the unidentified 

means for processing allegedly in Ogawa or (ii) withdraw the 

rejection. 

Claim 19 provides that the peripheral means comprises a 
first plurality of the peripheral means internal to the means for 
processing and a second plurality of the peripheral means external 
to the means for processing, wherein each of the peripheral means 
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is configured to perform a different operation on the incoming 
packet. In contrast, Wilford appears to be silent regarding each 
of the modules of memory (asserted similar to the claimed 
peripheral means) configured to perform a different operation on an 
incoming packet. Therefore, Ogawa and Wilford, alone or in 
combination, do not appear to teach or suggest a plurality of 
peripheral means comprising a first plurality of the peripheral 
means internal to a means for processing and a second plurality of 
the peripheral means external to the means for processing, wherein 
each of the peripheral means is configured to perform a different 
operation on the incoming packet as presently claimed. As such, 
claim 19 is fully patentable over the cited references and the 
rejection should be withdrawn. 

Claim 20 depends from independent claim 16, which is now 
believed to be allowable. As such, the presently pending invention 
is fully patentable over the cited references and the rejection 
should be withdrawn. 

COMPLETENESS OF THE OFFICE ACTION 

Aside from a notice of allowance, Applicant's 

representative respectfully requests any further action on the 

merits be presented in a new action. MPEP §707.07 (f) reads: 

Where the applicant traverses any rejection, the examiner 
should, if he or she repeats the rejection, take note of the 
applicant's argument and answer the substance of it. 
(Emphasis added) 



Applicant's representative traversed the rejection of claim 16 in 
the Office Action for lack of evidence that Ogawa expressly or 
inherently discloses the claimed structure. The Examiner was 
specifically requested to "provide a clear and concise explanation 
how the cited paragraphs of Ogawa allegedly anticipate the claimed 
structure." The current Office Action repeats the rejection of 
claim 16 and improperly repeats the use of the steps in method 
claim 1 to reject the structure of apparatus claim 16. The current 
Office Action fails to answer the substance of the traverse raised 
in the previous amendment regarding Ogawa 's alleged anticipation of 
the structure of claim 16. As such, the current Office Action is 
incomplete and either a notice of allowance or a new Office Action 
on the merits should be issued. 

Accordingly, the present application is in condition for 
allowance. Early and favorable action by the Examiner is 
respectfully solicited. 

The Examiner is respectfully invited to call the 
Applicant's representative should it be deemed beneficial to 
further advance prosecution of the application. 
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Account No. 50-0541. 



submitted, 

I 

]?. MA 10 RAN A, P.C, 




Chr l^txr&fieXJHJ MajV Qrana__ 
Registration No. 42,829 
24840 Harper Avenue, Suite 100 
St. Clair Shores, MI 48080 
(586) 498-0670 



Dated: June 6, 2005 



Docket No.: 0325.00483 
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the ISO r I? m ° del 15 deSCrib6d h6re f ° r What * defines - Remember that 

the ISO has defined its own protocols, but these are not widely used in the industry 
The more popular TCP/IP and IPX protocols are mentioned with respect toX ^ers 
m which they res.de. Note that the bottom physical layer is discusse/fir* Cdarity 

J^1?™ C £ L UY ? • ^ phySiCal layer defines the P h y sical characteristics of the 
™St l' i 38 mechamcal components and connectors, electrical aspects such as 
voltage levels representing binary values, and functional aspects such as setting up 
mamtairung, and taking down the physical link. Well-known physical layer interfaces 
for data communication include EIA RS-232 and RS-449, the successor to RS-232. 
RS-449 allows longer cable distances. Well-known LAN (local area network) systems 
are Ethernet, token ring, and FDDI (Fiber Distributed Data Interface). 

THE DATA LINK LAYER The data link layer defines the rules for sending and 
receiving information across a physical connection between two systems, ifs main 

ZIZZ f ^ d f S !T en * by Uppet n6tWOrk ^ - to and send 

r^ JJ f u t ^ ^ m thC reC6ivin S S y Stem can then acknowledge 
nn?n? n fra ^ fore the sender «nds another frame. Note that the data link is a 
point-to-point link between two entities. The next layer up, the network layer handles 

iTnksTo ^°' P T tlinkS * *" ^ Where frameS ^ transmitted across mXle 
hnks to reach their destination. In broadcast networks such as Ethernet a MAC 
(medium access control) sublayer was added to allow multiple devices to share 
and contend for the use of the same medium. See "Data Link Protocols." 

bTtLT^T ^ ** ^ ^ l3yer is USed to contro1 communication 

between two devices that are directly connected together, the network layer provides 
mternetwork services. These services will ensure that a packet of Wormatior!reIcnes 
its destination when traveling across multiple point-to-point links, i.e., a setT 

mSTIfl n t tWOlkS r °V terS - The netWOrk ^ basica % ma nages 

multiple data link connections. On a shared LAN, packets addressed to devices on the 
same LAN are sent using data link protocols, but if a packet is addressed to a devke 
on another LAN, network protocols are used. In the TCP/IP protocol suite, IP is the 
network ayer internetworking protocol. In the IPX/SPX suite, IPX is the network 
Protocol ° Intemetworkin 8'" " IP Onteniet Protocol)," and "Network Layer 

moviI^ PO ? T ^l ER Th " e tranSp ° rt layer pr ° vides a ^ Ievel of control for 
moving information between the end systems in a communication session. The end 

TWn^ 0I \ ? ^ netW0Tk M ° n different Networks of an internetwork. 
Transport layer protocols set up a connection between source and destination and 
send data in a stream of packets, meaning that each packet is numbered sequentially 
and constitutes a flow that can be monitored to ensure proper delivery andMentity in 
the flow. This flow is often called a virtual circuit, and the circuit may be preestablishS 
through specific router paths in an internetwork. The protocol also regulates the flow 
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of packets to accommodate slow receivers and ensures that the transmission is not 
completely halted if a disruption in the link occurs. (In other words, it will keep trying 
to send until a time-out occurs.) TCP and SPX are transport layer protocols. See "TCP 
(Transmission Control Protocol)" and "Transport Protocols and Services" for more 
information. 

THE SESSION LAYER The session layer coordinates the exchange of information 
between systems by using conversational techniques, or dialogs. Dialogs can indicate 
where to restart the transmission of data if a connection is temporarily lost, or where 
to end one data set and start a new one. This layer is a remnant of mainframe/ 
terminal communications. 

THE PRESENTATION LAYER Protocols at this layer are for presenting data 
Information is formatted for display or printing in this layer. Codes within the data, such 
as tabs or special graphics sequences, are interpreted. Data encryption and the 
translation of other character sets are also handled in this layer. Like the session layer 
tnis layer is a remnant of mainframe/ terminal communications. ' 

THE APPLICATION LAYER Applications access the underlying network services 
using defined procedures in this layer. The application layer is used to define a range 
of applications that handle file transfers, terminal sessions, and message exchange (for 
example, electronic mail). 5 v 

RELATED ENTRIES , Connection-Oriented and Connectionless Services- Data 
Communication Concepts; Data Link Protocols; Internet Organizations and 
Committees; Protocol Concepts; and Standards Groups, Associations, and 
Organizations 

INFORMATION ON THE INTERNET 

ISO (International Organization for http: / / www.iso.ch 
Standardization) 

ISO's list of OSI standards http://www.iso.ch/cate/3510001.html 
Cisco Systems' OSI paper http://www.cisco.com/univercd/data/doc/ 

cintrnet / ito / 551 65.htm 



OSPF (Open Shortest Path First) Protocol 

OSPF is a link-state routing algorithm that was derived from work done with IS-IS 
(Intermediate System-to-intermediate System), and OSI intradomain routing 
protocols. Link-state routing, as compared to distance-vector routing, requires more 
processing power but provides more control over the routing process and responds 
faster to changes. The Dijkstra algorithm is used to calculate routes. See "Routing 
Protocols and Algorithms" for more information. 



